feat: Screen Config Postgres Client APIs and Admin Logic - #3231

For my own understanding, we have a mix of @doc comments and blocks of comments (e.g.). How do we determine what we want to doc with @doc vs not?

I do need to be consistent with this 😅 I kind of like the @doc comments because of how they integrate with tools like ElixirLS in VSCode. But I do generally think the @doc comments are moreso for API consumers, which is why we generally don't have them throughout our codebase. I'll move towards consistency here, which I'd like to be @doc comments for this new file at least

The Elixir convention as far as I've seen is @doc for public functions and # blocks for private functions, since private functions are treated as "hidden" anyway and there's no way to access docs attached to them beyond looking at the code. Technically the main purpose of @doc is in generating ExDocs which are made available on Hex for published libraries; in an application codebase, it's mostly useful for editor LS integration. I usually include them if there's something important for callers to know that isn't covered by the function name, argument names, and typespec, which is all also readily accessible via LSP. (This is not just "for API consumers" in the sense of "consumers of some API external to the whole application", but if you take an expansive view of an "API" as "the set of public functions exported by a module", then that is accurate!)

Non-blocking nit - it looks like the parameter name (or type, depending how you look at it) here is omitted:

But looking at it's usage here, maybe its type is more than that of type string?

where in the else clause, result.error can be undefined, and if the catch clause, error is of type unknown. Keeping the API boundary between components the same, one potential type-safe solution could be:

      if (result.success === true) {
        onSuccess();
      } else if (result.error) {
        onError(result.error);
      } else {
        onError(`An unknown exception occurred updating the config`);
      }
    } catch (error: unknown) {
      if (error instanceof Error) {
        onError(error.message);
      } else if (error && typeof error === 'object' && 'toString' in error) {
        onError(error.toString())
      } else {
        onError(`An unknown exception occurred....we would need to make this distinct from the other exception where we have no idea what happened`);
      }
    }

you're right! Parsing these unknown/undefined errors into strings seems like a good solution to me